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(54) Distributed system and method for controlling acces to network resources 



(57) An access control database defines access 
rights through the use of access control objects. The ac- 
cess control objects include group objects, each defin- 
ing a group and a set of users who are members of the 
group, and rule objects. Some of the rule objects each 
specify a set of the group objects, a set of the manage- 
ment objects, and access rights by the users who are 
members of the groups defined by the specified set of 
the group objects to the specified set of management 
objects. A plurality of access control servers are used 
to process access requests. Each access control server 
controls access to a distinct subset of the management 
objects in accordance with the access rights specified 



in the access control database. At least one of the ac- 
cess control servers receives access requests from the 
users and distributes the received access requests 
among the access control servers for processing. A sub- 
set of the access requests specify operations to be per- 
formed on specified sets of the management objects. 
Each of these access requests is sent for processing to 
one or more of the access control servers in accordance ■ 
with the management objects to which access is being 
requested. The access control servers responding to 
the access requests from the users by granting, denying 
and partially granting and denying the access requested 
in each access request in accordance with the access 
rights specified in the access control database. 
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Description 

[0001] The present invention relates primarily to the 
management of computer networks, and more particu- 
larly to a system and method for limiting access to a 
computer network's management objects to authorized 
users of the network management objects. 

BACKGROUND OF THE INVENTION 

[0002] SNMP (Simple Network Management Proto- 
col) was developed to provide a tool for multivendor, in- 
teroperable network management. SNMP provides a 
set of standards for network management, including a 
protocol, a database structure specification, and a set 
of data objects. SNMP was adopted as the standard for 
TCP/IP-based internets in 1989. 
[0003] An explanation of SNMP technology is beyond 
the scope of this document and the reader is assumed 
to be either conversant with SNMP or to have access to 
conventional textbooks on the subject, such as William 
Stallings, "SNMP, SNMPv2and RMON," Addison Wes- 
ley (1996), which is hereby incorporated by reference in 
its entirety as background information. 
[0004] CMIP is a network management protocol like 
SNMP, except that it is based on OSI standards. The 
book : "SNMP, SNMPV2 and CMIP: The Practical Guide 
to Network Management Standards" by William Stall- 
ings, which is an excellent source of basic information 
on CMIP, and on CMIP related standards, is hereby in- 
corporated by reference in its entirety as background in- 
formation. 

[0005] Many networks use a network manager and 
some form of Simple Network Management Protocol 
(SNMP) or CMIP for managing the network. Among its 
management tasks, the network manager automatically 
monitors the status of the devices on the network. The 
network manager sends event requests to the devices, 
which are requested to return responses when certain 
events occur. For example, a disk agent might be re- 
quested to send a response if available disk space falls 
below 50%. 

[0006] An SNMP-manageable (or CMIP-managea- 
ble) device stores in its memory a Management Infor- 
mation Base (MIB), a collection of objects or variables 
representing different aspects of the device (e.g., con- 
figuration, statistics, status, control). For each class of 
device, the MIB has a core of standard variables. Each 
vendor of a device will add to the core, variables that it 
feels are important to the management of its device. 
[0007] The MIBsfor the manageable devices in a net- 
work not only store management information that can 
be retrieved, but also contain variables whose values, 
when modified by a network manager, modify the oper- 
ation of the device. Simple examples are disabling a de- 
vice's operation, changing the priorities assigned to dif- 
ferent tasks performed by a device, and changing the 
set of messages generated by the device and the set of 



destinations to which those messages are sent. 
[0008] Clearly, it is important to prevent unauthorized 
persons from accessing the management information 
objects in a network. Otherwise, not only will confidential 

s information be obtained by unauthorized persons, but 
also the network would be open to acts of sabotage. The 
present invention addresses the subject of access con- 
trol for network management information objects. 
[0009] ITU-T X.741 (1995) is an industry standard, 

10 published by the Telecommunication standardization 
sector of the International Telecommunication Union, 
previously known as the CCITT, entitled Data Networks 
and Open System Communications, OSI Management. 
The X.741 standard specifies an access control security 

is model and the management information necessary for 
creating and administering access control associated 
with OSI (open systems interconnection) system man- 
agement. 

[001 0] There are a number of related ITU-T standards 
20 that relate to OSI systems management that are rele- 
vant to the present invention, particularly X.740 (1992) 
(security audit trail function) and X.81 2 (1 995) (data net- 
works and open systems communications security). All 
three of these ITU-T standards, X.741 (1995), X.740 
25 (1 992) and X.B1 2(1 995) are hereby incorporated by ref- 
erence as background information. 
[0011] While the X.741, X.740 and X.81 2 standard de- 
fine a fairly comprehensive access control framework 
for controlling access to network management objects, 
30 there remain numerous access control and manage- 
ment issues that are not addressed or resolved by these 
standards. 

[0012] In particular, when a network has tens or hun- 
dreds of thousands of components (herein called ob- 

35 jects), using a single management server to process all 
access requests may cause service bottlenecks. The 
standards discussed above do not address the subject 
of efficiently managing access control to management 
objects in large networks. 

40 [0013] Examples of the present invention provide a 
distributed access control system that can efficiently 
handle large numbers of access requests to a large net- 
work having tens or hundreds of thousands of manage- 
ment objects. 

45 [0014] While X.741 and the related standards define 
access control for limiting access to management ob- 
jects, these standards do not address or specify any 
mechanism for limiting access to event reports. Event 
reports (usually called event notifications), such as the 

so reports generated when an object is created, deleted, 
or a management parameter passes a specified thresh- 
old, in many systems are broadcast to all listeners. This 
is clearly unacceptable if the network is, for instance, 
the telephone switching network owned by a large tele- 

ss communications company, and the event reports con- 
cern resources being installed or utilized for a particular 
customer. That is, customer A should not be allowed to 
receive event reports about network resources being 
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used on behalf of customer B. 

[0015] In fact, the presumption in X.741 and the relat- 
ed standards is that event report security should be im- 
plemented using a mechanism that is separate from the 
access control mechanism used for restricting access s 
to management objects. After all, access contralto man- 
agement objects filters inbound messages requesting 
access to objects, while event reports are outbound 
messages. 

[0016] However, it has been observed by the inven- 10 
tors of the present invention that in many cases, the ob- 
jects that a person is to be prohibited from accessing 
are also the objects from which that person should not 
be receiving event reports. For instance, using the 
above example, employees of customer A should nei- 15 
ther access nor receive event reports for any of the ob- 
jects that have been allocated to customer B. 
[0017] Therefore examples of the present invention 
provide an integrated security system for restricting ac- 
cess to management objects and event reports. 20 
[0018] Finally, customers of large networks are de- 
manding the ability to generate network management 
reports using "SQL" (structure query language) type re- 
port generators. That is, users of such networks want 
the ability to generate reports on the status of their net- zs 
work resources, while avoiding the complexities of net- 
work management information retrieval using SNMP (or 
any other network management protocol). X.741 and 
the related standards do not call for, or even suggest, 
any type of direct or SQL type access to the manage- so 
ment object database for the purpose of generating 
management reports. In fact, direct SQL type access 
might be seen as contrary to the goals of X.741 since it 
is a potential source of security leaks. 
[0019] Examples of the present invention further pro- 35 
vide direct SQL type access to the management object 
database for purposes of report generation, as opposed 
to othertypes of object access. The purposeof the direct 
access mechanism is to allow users to use standard 
DBMS report generators to define and generate reports 40 
about the status or past performance of n etwork objects, 
while still providing the same access restrictions as 
those that apply to normal management information ac- 
cess requests. 

45 

SUMMARY OF THE INVENTION 

[0020] In summary, the present invention is a system 
and method for controlling access to management ob- 
jects in a computer network. An access control database so 
defines access rights through the use of access control 
objects. The access control objects include group ob- 
jects, each defining a group and a set of users who are 
members of the group, and rule objects. Some of the 
rule objects each specify a set of the group objects, a 55 
set of the management objects, and access rights by 
the users who are members of the groups defined by 
the specified set of the group objects to the specified set 



of management objects. 

[0021] A plurality of access control servers are used 
to process access requests. Each access control server 
controls access to a distinct subset of the management 
objects in accordance with the access rights specified 
in the access control database. At least one of the ac- 
cess control servers receives access requests from the 
users and distributes the received access requests 
among the access control servers for processing. A sub- 
set of the access requests specify operations to be per- 
formed on specified sets of the management objects. 
Each of these access requests is sent for processing to 
one or more of the access control servers in accordance 
with the management objects to which access is being 
requested. 

[0022] The access control servers responding to the 
access requests from the users by granting, denying 
and partially granting and denying the access requested 
in each access request in accordance with the access 
rights specified in the access control database. 
[0023] One of the access control servers is a manage- 
ment information server that receives the access re- 
quests submitted by users to the access control system. 
The management information server partitions an ac- 
cess request into two or more access sub-requests 
when access to the set of management objects speci- 
fied by the access request is controlled by two or more 
of the access control servers, and sends the access 
sub-requests to those two or more access control serv- 
ers for processing. The management information server 
also combines responses to the two or more access 
sub-requests generated by the access control servers 
when processing the access sub-requests and returns 
a combined response to the user who submitted the ac- 
cess request that was partitioned. 
[0024] A second subset of the rule objects in the ac- 
cess control database are used to specify access rights 
to the access control objects. An access control data- 
base server stores the access control database in per- 
sistent storage, receives access requests to the access 
control objects, and grants and denies the access re- 
quests to the access control object in accordance with 
the access rights specified in the access control data- 
base. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0025] Additional objects and features of examples of 
the invention will be more readily apparent from the fol- 
lowing detailed description and appended claims when 
taken in conjunction with the drawings, in which: 
[0026] Fig. 1 is a block diagram of an access control 
engine for restricting access to the management objects 
in a network. 

[0027] Fig. 2 depicts the data structure of an access 
request. 

[0028] Fig. 3 depicts a distributed access control en- 
gine (ACE) in accordance with a preferred embodiment 
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of the present invention. 

[0029] Fig. 4 depicts the access control database and 
a mechanism for adding objects to the database and for 
modifying the objects already in the database. 
[0030] Fig. 5 depicts the order in which access rules 
are applied for processing each access request. 
[0031] Fig. 6 depicts a procedure for processing an 
access request, dividing it among the responsible ac- 
cess servers, collating the responses and returning a 
combined response to the initiator. 
[0032] Fig. 7 depicts a chart for indicating how access 
request responses are combined when the target of an 
access request includes more than one management 
object. 

[0033] Fig. 8 depicts the event registry and event rout- 
er portions of a management information server in a pre- 
ferred embodiment of the present invention. 
[0034] Fig. 9 depicts a supplemental access mecha- 
nism for providing SQL type read only access to log 
records, relating to event notifications generated by 
management objects, while maintaining the same secu- 
rity restrictions on access to management object infor- 
mation as that provided by the management information 
server for the network. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

[0035] Referring to Fig. 1, there is shown a network 
management system 100 having an access control en- 
gine (ACE) 102 that restricts access by initiators 104 (e. 
g., users, and application programs acting on behalf of 
users) to the management objects in a network 1 06. The 
network 106 can be virtually any type of computer im- 
plemented network that uses a management protocol 
for performing management functions. For the purposes 
of this document, we are only concerned with the man- 
agement objects in the network, which contain manage- 
ment information and resource control variables. Fur- 
thermore, for the purposes of this document, we are pri- 
marily concerned with methods of restricting access to 
management objects and to event notifications gener- 
ated by management objects, and thus we are not par- 
ticular/ concerned with the content and functions of the 
management objects. 

[0036] It should be noted that in many documents, 
management objects are called "managed object in- 
stances" (MOI's). In such documents, the abbreviations 
"Ol" and "OC" stand for "object instance" and "object 
class." In the terminology of this document, an object is 
in fact an object instance, because every object is an 
instance of a respective object class. For instance , each 
"router management object" in a network is an instance 
of a respective router management object class. Except 
when deemed necessary for clarity, the term "object" will 
be used instead of "object instance" in this document. 
Also, in the preferred embodiment all the management 
objects and access control objects are GDMO compli- 



ant. 

[0037] The access control engine contains an access 
control database 1 08. Like the network itself, the access 
control database 108 consists of a hierarchy of objects. 
5 Various aspects of the access control database, as im- 
plemented in the present invention, will be described in 
more detail below. The access control database 108 
contains access control rules, which can be applied to 
access requests in order to determine whether such re- 
w quests should be denied or granted. 

[0038] An access control decision function (ACDF) 
110 is the procedure (or set of procedures) that applies 
the access control rules to each access request so as 
to determine whether the requested access to a man- 
's agement object should be granted or denied. As will be 
discussed in more detail below, when an access request 
has a target of more than one management object, 
some portions of an access request may be granted 
while other portions are denied. 
20 [0039] An access control enforcement function 
(ACEF) 112 is the procedure (or set of procedures) for 
enforcing the decisions made by the ACDF 110. In par- 
ticular, the ACEF 112 sends access denial responses 
when the ACDF 110 returns an access denial, and for- 
25 wards the access request to the appropriate network 
management objects when the access is granted. 
[0040] Referring to Fig. 2, each access request 120 
is a data structure or object containing a set of prede- 
fined fields, including: 

30 

• user information, identifying the request initiator; 

• operation, which is the type of operation to be per- 
formed on the specified target object(s); defined op- 
erations include get, set, create, delete, action, fil- 

35 ter, multiple object selection, and "receive notifica- 
tions from"; note that the "receive notifications from" 
operation (usually called the "event notification" ac- 
tion elsewhere in this document) is not one of the 
operations defined by X.741 , but rather is a new op- 

40 eration added by the inventors for reasons that will 
be explained below; 

• mode, equal to confirmed or unconfirmed, which in- 
dicates whether or not the management information 
server should send response messages to the ini- 

45 tiator; when the mode is equal to unconfirmed, re- 
sponse messages (e.g., access denial messages) 
are not sent to the initiator; when the mode is equal 
to confirmed, response messages are sent to the 
initiator; 

so • synch, equal to "atomic" or "best effort"; if synch is 
set to atomic, an access request directed at more 
than one object is aborted if any portion of the re- 
quest is denied; if synch is set to best effort, the ac- 
cess request is executed on the objects to which 

55 access is granted and the corresponding results are 
returned to the initiator; and 

• target, which specifies the object or objects the ini- 
tiator wants to access. 
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[0041] The target in the access request 1 20 is speci- 
fied by three fields: 

• base object, which indicates a particular object in 
the network management object tree; 

• scope, which indicates the range of objects above 
or below the base object in tree to be accessed; in 
the preferred embodiment base objectis always the 
object in the target set that is closest to the root and 
the scope indicates a number of object tree levels 
below (i.e., further from the root) the base object 
that are to be included as part of the target set; and 

• filter, which sets out a filter condition (e.g., a filter 
might indicate that only management objects for 
routers in Menlo Park, California are to be included 
in the target set) for restricting the set of objects in- 
cluded in the target set; the filter field is the equiv- 
alent of a "where" clause in an database query. A 
filter can also be used to specify the type of event 
notifications the user wishes to receive (e.g., SNMP 
or CMIP event notifications). 

[0042] A request that has a target set of just one ob- 
ject, because the scope field in the request is unused, 
is considered to be a °non-scoped" request. A request 
that has a target set of more than one object, because 
the scope filed in the request indicates more than one 
object is to be accessed, is considered to be a "scoped" 
request. 

Distribution of Access Control Over Several Servers 

[0043] Referring to Fig. 3, the functions of the access 
control engine 102 (Fig. 1) are distributed over a plurality 
of servers so as to increase the speed with which access 
control is handled. It should be understood that the fol- 
lowing explanation of Fig. 3 will contain brief "overview" 
explanations of the functions performed by some of the 
system components shown in Fig. 3, and that more de- 
tailed explanations of those aspects of the invention not 
specified in the above referenced standards (e.g., X. 
741) will be provided in other sections of this document. 
[0044] In many instances, such as telephone net- 
works, the number of network management objects is 
extremely large, the number of persons requiring ac- 
cess to the management objects is correspondingly 
large, as is the daily volume of access requests. Most 
access requests are fairly narrowly focused. For in- 
stance, a typical access request will request access to 
the management objects of a particular type at a partic- 
ular location. In another example, if a part of the network 
needs to be shut down for repairs, the target set for the 
access request will designate the management objects 
for the devices to be shut down. Other access requests, 
especially status information gathering requests, can in- 
clude very large target sets. 

[0045] A management information server (MIS) 150 
receives all management object access requests 120, 



and distributes each request, or portions of the request, 
to a set of auxiliary servers 152 in accordance with the 
portion(s) of the management object tree referenced by 
the request. Each server 1 50 and 1 52 performs both ac- 
s cess control functions and the request response gath- 
ering functions. Thus, access control processing is di- 
vided among the MIS 150 and auxiliary servers 152, en- 
abling faster processing of access requests during pe- 
riods of heavy request traffic. 
10 [0046] In particular, the MIS 150 only performs access 
control for objects at the top of the management objects 
tree, while each of the auxiliary servers performs access 
control for objects in respective designated subtrees of 
the management objects tree. One important exception 
15 to the above statement is that all access requests for 
event notifications (i.e., with an operation of "receive no- 
tification from") are delivered to an event registry mod- 
ule in the MIS, regardless of which objects are the tar- 
gets of the access request. This is discussed in more 
20 detail below with respect to event notification access 
control. 

[0047] In addition, a special auxiliary server 154 is 
used to handle all updates to the access control object 
tree 170 (which is not the same as the prior art access 
25 control tree 108, for reasons that will be explained be- 
low). In some implementations, the special auxiliary 
server 154 may be merged with the MIS 150 or one of 
the regular auxiliary servers 152. Alternately, in systems 
with relatively low access request traffic, the special 
30 auxiliary server 1 54 can be implemented as a separate 
software entity on the same physical server hardware 
as one of the other servers. 

[0048] The MIS 150 and each auxiliary server 152, 
154 stores a full copy of the access control object tree 
35 170, but is responsible only for processing requests to 
access a respective portion of the network management 
object tree. In an alternate embodiment, each of the MIS 
and auxiliary servers could store just the portion of the 
access control object tree 1 70 needed to perform its as- 
40 signed access control functions. 

[0049] If an access request has target objects in the 
portions of the management object tree that are serv- 
iced by more than one server, the access request is split 
into access sub-requests by the MIS 150 and sent to the 
45 appropriate auxiliary servers 152. The access sub-re- 
quest responses generated by all the servers are collat- 
ed by the MIS 1 50 and returned together to the request- 
ing user or application. 
[0050] The MIS 150 includes: 

so 

• an interface 160 for receiving access requests; 

• one or more central processing units (CPU's) 162 
for executing access control procedures stored in 
the MIS's memory 164; 

55 • memory 164, including both volatile high speed 
RAM and non-volatile storage such as magnetic 
disk storage; 

• an interface 166 for handling secure communica- 
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tions between the MIS 150 and the auxiliary access 
control servers 152, 154; and 

• one or more internal busses 1 68 for communicating 
data and programs between the above referenced 
elements of the MIS 150. 

[0051] The memory 1 64 may store: 

• a partial or complete copy 1 70 of an access control 
tree; it should be noted that the access control tree 
170 in the preferred embodiment has different com- 
ponents and organization than those specified in X. 
741, and therefore the access control tree 108 in 
Fig. 1 is not the same as the access control tree 170 
used in the present invention; 

• an access request partitioning and routing proce- 
dure 172 for partitioning access requests into ac- 
cess sub-requests and routing the access sub-re- 
quests to the appropriate server(s) for access con- 
trol processing; 

• a subtree to server mapping table 1 73, which stores 
the information necessary for the MIS 150 to deter- 
mine the server or servers to which each access 
request should be sent for access control process- 
ing; 

• an access control enforcement function 1 74, whose 
functionality is the same as that of the ACEF 112 
shown in Fig. 1 ; 

• an access control decision function 176, whose 
functionality is the same as the of the ACDF 110 
shown in Fig. 1 ; 

• a request response combining procedure 178 for 
merging the responses generated by the various 
servers to each distinct access request and return 
a single, combined response to the initiator; 

• an array 1 80 of status information about access re- 
quests whose processing has not yet been complet- 
ed; 

• a security audit trail 182, for keeping a record of all 
access requests; 

• an event registry 184, which is a mechanism for 
keeping track of event notifications that particular 
users have requested; and 

• an event router 1 86, which is a module for sending 
event notifications to users or applications who 
have (A) requested those event notifications, and 
(B) who are authorized to receive them. 

[0052] Other aspects of the MIS 1 50 not shown in Fig. 
3 will be described below. 

[0053] The Ml S 1 50 and auxiliary servers 1 52, 1 54 all 
maintain identical copies of a library of access control 
procedures as well as a copy of the access control ob- 
ject tree 170. 

[0054] Thus, each auxiliary server 152, 154 includes 
the same hardware and software elements found in the 
MIS 150, except for (A) the special procedures (172, 
.178) in the MIS used for handling the receipt and parti- 



tioning of access requests, and the combining of re- 
sponses, and (B) they each have just one interface 
160/166 for receiving access requests and returning re- 
sponses. Each auxiliary server 1 52 retains either a com- 

s plete copy 1 70 of the access control object tree, or the 
portion of it needed to handle the access requests to be 
handled by that auxiliary server. 
[0055] The special auxiliary server 154 maintains a 
copy 190 of the access control object tree 170 in per- 

10 sistent storage so that the access control objects are 
available for use by all the access control servers when- 
ever the access control system, or any portions of it, is 
re-booted or restarted for any reason. The special aux- 
iliary server 154 is also responsible for handling all up- 

« dates to the access control object tree 170. 

[0056] In addition to the access control library proce- 
dures shared with the other servers, the special auxiliary 
server 1 54 has an additional procedure 1 94 for handling 
access control to the access control object tree 170/1 90 

20 and for handling updates of the access control object 
tree 170/190. The same type of access control that is 
used to restrict access to management objects is also 
used to restrict access to the access control object tree 
190/170. In other words, some of the target objects and 

25 rule objects in the access control object tree 170 are 
used to define access rights to the access control ob- 
jects, and the special auxiliary server 154 restricts ac- 
cess to the access control objects in accordance with 
the rules defined by those access control objects. In this 

30 way only authorized users can access and update the 
access control object tree 190/170. 
[0057] The MIS 150 has enough knowledge of the ob- 
ject tree in the network to know which auxiliary servers 
are needed to service each request. In particular, the 

35 MIS 1 50 has an access request partitioning and routing 
procedure 172 and a mapping table 173 that stores in- 
formation identifying a set of "tree division point objects" 
(also called division point nodes). More specifically, the 
mapping table 173 contains a sequence of records. 

40 Each record identifies a management object subtree, 
identified by a topmost object called a tree division point 
object, and also identifies the server 152 for handling 
the access requests to objects in that management ob- 
ject subtree. For each access request, the MIS 150 first 

45 applies the "global deny rules," as will be explained in 
more detail below. If the request is not rejected by a glo- 
bal deny rule, the MIS 150 then traverses the network 
object tree 170 so as to identify the server or servers 
required to further process the access request. 

so [0058] More specifically, for each received access re- 
quest (other than access requests for event notifica- 
tions) the MIS traverses the network object tree until it 
reaches any of the division point objects. Since all man- 
agement objects below the division point objects are to 
55 be processed by a corresponding auxiliary server, the 
tree traversal stops at those objects. Depending on how 
the access management duties have been divided 
among the servers, it is possible that a single access 
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request will have to be partitioned into two or more ac- 
cess sub-requests and sent to two or more of the servers 
for further processing. When a request is partitioned for 
processing by more than one server, the base object 
and scope portions of the each partition of the access 
request (i.e., each sub-request) are modified so as to 
only encompass the portion of the management object 
tree serviced by the corresponding server. 
[0059] The MIS 1 50 also maintains status information 
180 on each access request whose processing is not 
yet completed. The status information 180 identifies all 
the servers from which partial responses are needed be- 
fore a complete response can be returned to the initiator. 
[0060] Depending on the implementation, the MIS 
1 50, in addition to applying the global deny rule to each 
request, may also be responsible for restricting access 
to various portions of the management object tree not 
allocated to any of the auxiliary servers. For instance, 
the MIS 150 will typically be responsible for restricting 
access to the root node of the management object tree 
and can also be made responsible for any particular 
branch of the management object tree. 
[0061] In an alternate embodiment, access control re- 
sponsibilities could be divided among the servers in oth- 
er ways, for instance on the basis of the type of operation 
to be performed on the target objects. Thus, one server 
might be responsible for handling set operations, anoth- 
er create and delete operations, and so on. 
[0062] The access security rules are stored in persist- 
ent storage, with recently used portions also stored in 
cache memory, at the MIS 150 and each auxiliary server 
152. Whenever any access control rule is updated, de- 
leted or added to the system, the rule base in every aux- 
iliary server is updated in synchronized fashion using an 
event propagation mechanism that is also used for han- 
dling other types of event messages. The process for 
updating the access control tree 108 will be explained 
in more detail below. 

The Access Control Database 

[0063] While X.741 indicates that object access is to 
be controlled on a user by user basis, the present inven- 
tion controls object access on a group by group basis. 
The user group feature helps to greatly reduce the 
amount of data required to define each access rule. 
Each user authorized to access information in the sys- 
tem is assigned to one or more groups. Access rules 
are defined in terms of access rights of groups. For in- 
stance, object parameter reading rights are likely to be 
assigned using different groups than object parameter 
setting rights. Also, rules are typically defined hierarchi- 
cally with respect to these groups, for instance denying 
access to Customer A's subtree of objects to everyone 
who is not either a Customer A group member or a sys- 
tem administrator group member, and then further de- 
fining rights to objects within Customer A's subtree in 
accordance with groups of users set up by Customer A. 



[0064] Referring to Fig. 4, the primary components of 
the access control tree 170 are group definitions 200, 
user definitions 202, target definitions 204, access rules 
206, and default rules 208. 
5 [0065] Each group definition 200 is represented by a 
group object, having the following fields: 

• group name; and 

• a list of users included in the group. 

10 

The group objects are used to map groups to users. 
[0066] Each user definition 202 is represented by a 
user object, having the following fields: 

is * user name; and 

• list of groups of which the user is a member. 

The user objects are used to identify all the groups to 
which a particular user belongs. 

20 [0067] It should be noted here that the term "users- 
includes entities other than users that can be granted 
access rights. For instance, the auxiliary servers, the log 
server, and even objects in the system can be set up as 
"users" for the purpose of defining access rights to be 

25 accorded to those entities. 

[0068] Each target definition 204 is represented by a 
target object, having the following fields: 

• target name; and 

30 • a list of base management objects that are to be 
included in the target set identified by this target ob- 
ject; 

» a list of management object classes; this field is 
used only when a target set includes all the man- 
as agement objects of a particular class, subject to the 
filter condition (see below); 

• scope, indicating the number of management ob- 
ject tree levels below the listed base management 
objects that are to be included in the target set; and 

40 • a filter, which is an optional field used to restrict the 
set of objects included in the target set; the filterfield 
is the equivalent of a "where" clause in an database 
query; and 

• an operations list, which lists the operations (get, 
45 set, etc.) for which the target set is applicable. 

[0069] Each rule definition 206 is represented by a 
rule object, having the following fields: 

so • a rule name for identifying the rule; 

• a group list, that identifies all the user groups to 
which the rule is applicable; 

• a targets list, which is a list of the target objects to 
which the rule is applicable; and 

55 • an enforcement action, indicating whetherthe spec- 
ified groups of users have or do not have access to 
the specified target set; in a preferred embodiment 
the enforcement action can be set to Deny with Re- 
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sponse, Deny without Response, or Grant. 

[0070] Default rules 208 are represented by a default 
rules object, having the following fields: 

s 

• a list of default enforcement actions for a corre- 
sponding predefined list of operations (e.g., get, set, 
create, delete, etc.); the most typical list of default 
enforcement actions is to deny access for all oper- 
ations types, but in some implementations the sys- 10 
tern administrator might decide to make the default 

for some operations, such as the get operation, to 
be "grant"; 

• a default enforcement action for event notifications; 
and 15 

• a default denial response (i.e., deny with response 
or deny without response). 

[0071] The defaults 208 are default responses that 
are defined for each operation when no rule has been 20 
defined that applies to a particular access request. For 
instance, the defaults could be set to "Grant" access re- 
quests whose operation is "Get", and to 'Deny with Re- 
sponse" access requests whose operation is anything 
other than "Get". However, it is expected that in most « 
implementations all the defaults will be set to either "De- 
ny with Response" or "Deny without Response". The de- 
faults 208 are preferably defined by a single Default ob- 
ject which contains a grant or deny flag for each of the 
defined operations. 30 
[0072] Each "rule" in the access control tree either 
grants or denies access by certain groups of users 
(identified by the group objects referenced in the rule 
object) to a set of target objects, specified by a target 
object referenced in the rule object. Unlike X.741 , ac- 35 
cess rules are not defined on a user by user basis, but 
instead on a group by group basis. As a result, as par- 
ticular users join and leave the employment of a com- 
pany using the present invention, only the user and 
group objects need to be updated, instead of having to 40 
update all the rule objects that applied to those users. 
[0073] In addition to rule objects that specify a set of 
target management objects, the system can have one 
global deny rule object and one global allow rule object. 
Each of the global rule objects has the same structure « 
as a regular rule object, but has any empty target list 
field, which indicates the rule is a global rule. The global 
deny rule, if defined, specifies groups of users that can- 
not perform any operations on any management ob- 
jects. The global grant rule, if defined, specifies groups so 
of "super users" (e.g., system administrators) that are 
allowed to perform all operations on all management ob- 
jects. 

[0074] Whenever an object in the access control tree 
170 is added, deleted or modified, other access control 55 
objects may also have to be modified in order to keep 
the access control tree 170 self -consistent. For in- 
stance, if a user object is modified to delete all the 



groups previously included in the user object's group list 
and to make the identified user a member of a previously 
defined "DenyAII" group, all the group objects that used 
to be listed in the user object will have be updated to 
delete this user from their user lists, and the DenyAII 
group object will need to be updated by adding this user 
to its user list. In another example, if a target object is 
deleted from the access object tree 170, then all the rule 
objects that reference the deleted target object will need 
to be modified so as to remove the deleted target object 
from their target object lists. 

[0075] In order to ensure that the access control ob- 
ject tree 170 is maintained in a self-consistent state, all 
changes to the access control object tree 170 are per- 
formed by a procedure called the Access Control Con- 
figuration procedure 210. The Access Control Configu- 
ration procedure 210 presentsa graphical user interface 
21 2 to users authorized to modify the access control tree 
170. The Access Control Configuration procedure 210 
allows the authorized user to navigate, inspect and mod- 
ify the access control tree 1 70. Each time the authorized 
use r specifies a change to be made to the access control 
tree 170, the Access Control Configuration procedure 
21 0 also makes all the other changes to the access con- 
trol tree 170 required to keep it self-consistent. 

Applying Access Control Rules to Requests 

[0076] Referring to Fig. 5, the operation of the access 
control decision function 176 will first be explained with- 
out considering the impact of partitioning requests for 
processing by one or more servers. Later, request par- 
titioning and the division of duties among the servers will 
be explained. 

[0077] When an access request is received, the ac- 
cess request is compared successively with the global 
deny rule (step 220), the targeted deny rules (step 222), 
the global grant rule (step 224), and the targeted allow 
rules (step 226), in that order. The first rule found that 
matches the access request is applied to it (step 230). 
If no matching rule is found, then the appropriate default 
rule is applied (step 232). 

[0078] By applying the deny rules first, and then the 
grant rules, access denial rules are given higher priority 
than access grant rules. Also, this structure makes it rel- 
atively easy to define a set of access rules to grant cer- 
tain access rights to a broad group of users, but then 
specify subgroups to whom those access rights should 
be denied. 

[0079] When an access request has a target set with 
more than one target object, different rules may apply 
to different ones of the target objects specified by the 
request. In that case, the first rule found that is applica- 
ble to each particular target object or subgroup of target 
objects is applied to that target or subgroup of targets. 
As a result, some portions of an access request may be 
granted, while others are denied. 
[0080] Referring to Fig. 6, there is shown the se- 
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quence of actions performed by the access request par- 
titioning and routing procedure 172, the access control 
decision and enforcement functions 176, 174, and the 
request response combining procedure 178. Note that 
this discussion does not apply to access requests for s 
event notifications, which are handled separately by the 
event registry. 

[0081] Each access request is received by the MIS 
150, which then compares the access request with the 
global deny rule (step 240). If a match is found, the re- 10 
quest is denied, and a response is returned to the initi- 
ator if appropriate (step 242). No response is returned 
to the initiator when (A) the applicable global deny rule 
specifies an enforcement action of "Deny without Re- 
sponse", or (B) the request itself specifies an "uncon- >5 
firmed" mode. 

[0082] If no match was found with the global deny rule, 
the MIS compares the target set specified in the request 
with the subtree to server mapping table 173 to deter- 
mine the server or servers to which the request will be 20 
sent for processing (step 244). If the request's target set 
falls within the domain of more than one server, the ac- 
cess request is partitioned into sub-requests, and each 
sub-request is then sent to its respective server. When 
a request is partitioned, the target set in the original re- 25 
quest is adjusted for each sub-request so as to only 
specify target objects with the domain of the associated 
server. 

[0083] If the request's target set falls within the do- 
main of a single server, the entire request is forwarded so 
to that one server for processing. In some instances, the 
server for processing the request will be the MIS, in 
which case the request is added to the end of the MIS's 
local request queue. Each auxiliary server which re- 
ceives a request from the MIS puts the received re- 35 
quests on its local request queue for processing. The 
MIS maintains a status information array 180 (Fig. 3) for 
all outstanding access requests, with an indication of the 
server or servers to which they have been sent for 
processing. 40 
[0084] At each server to which an access request is 
sent for processing, the access request is executed by 
performing the access control decision function and 
then the access control enforcement function. More par- 
ticular, referring back to Fig. 5, steps 222 through 232 4S 
of the access control decision function are performed at 
each server, since step 220 has already been performed 
by the MIS. The deny/grant decision for each access 
request may be stored in a security audit trail. 
[0085] In a preferred embodiment of the present in- so 
vention, the access control decision function can be 
configured, through the use of a global configuration pa- 
rameter, to invoke any one of the following levels of "log- 
ging'' of access decisions in the security audit trail: (A) 
off, with no information being logged, (B) storing sum- 55 
mary information about access request grants and de- 
nials, denoting only the identity of the initiator, the re- 
quested operation, and the target object or set of objects 



to which access was granted or denied, and (C) a full 
logging level in which, for each access request grant or 
denial the entire access request is logged as well as full 
information about the target objects to which access 
was granted or denied. 

[0086] At each server, the responses generated by re- 
quests and sub-requests are determined and sent back 
to the MIS (step 246). Finally, at the MIS, if a request 
was partitioned into two or more sub-requests, the re- 
sponses are combined and the combined response, if 
any, is returned to the initiator (step 248). If a request 
was not partitioned, the response, if any, is forwarded 
to the initiator. Also, the access request is deleted from 
the pending request status table 180 (Fig. 3). 

Combining Responses When A Request has More than 
One Target Object 

[0087] Fig. 7 is a chart indicating how access request 
responses are combined when the target set of an ac- 
cess request includes more than one management ob- 
ject. The chart in Fig. 7 is applied only when access to 
at least one target object specified by a request has 
been denied. When access to all the target objects is 
granted, the responses generated by all the target ob- 
jects are simply combined and returned to the initiator. 
[0088] When there is only one object in the target set 
of a request, corresponding to the "non-scoped opera- 
tion" row of the chart in Fig. 7, there is no need to corrv 
bine responses If the request is a confirmed request the 
access denied response generated by the applicable 
rule is returned to the initiator. If the response generated 
by the applicable rule is a "deny without response", then 
no response is returned. If the request is an unconfirmed 
request, no response is returned regardless of whether 
the request is granted or denied. 
[0089] When a request specifies more than one target 
object, corresponding to the "scoped operation" portion 
of the chart in Fig. 7, the type of response returned de- 
pends on the request's synch parameter. If the request 
is an atomic request, when access to any of the target 
objects is denied the entire operation fails. If the request 
is a confirmed request, a single "access denied" re- 
sponse is returned to the initiator. Otherwise, if the re- 
quest is an unconfirmed request, no response is re- 
turned to the initiator. 

[0090] When the request specifies more than one tar- 
get object ("scoped operation") and specifies a "best ef- 
fort" synch mode, the responses generated by the ob- 
jects for which access is granted are returned to the us- 
er. For each object to which access is denied, an "ac- 
cess denied" response is returned if the request is a con- 
firmed request and the applicable rule has an enforce- 
ment action of "deny with response". Otherwise, if the 
applicable rule has an enforcement action of "deny with- 
out response", no response is returned for the object(s) 
to which access is denied. 

[0091] Finally, if the request was an unconfirmed re- 
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quest, no response is returned to the initiator regardless 
of which portions of the request were granted and which 
were denied. It should be noted that an unconfirmed re- 
quest cannot have a "get" operation, since by definition 
the purpose of a "get" response is to retrieve informa- 
tion. 

[0092] The response combining operation summa- 
rized in Fig. 7 is performed first at each server 1 50, 1 52 
where the request or sub-request is processed, and 
again at the MIS for those requests that are partitioned 
into sub-requests. For atomic access requests that are 
partitioned and processed at more than one server, the 
access control enforcement function is performed only 
after the results for the access control decision function 
have been combined by the MIS. When an access re- 
quest is processed at just one server (i.e., all its target 
objects fall within the domain of a single server 150, 
152), the response combining operation is performed 
only by the server processing the request. 

Limiting Access to Event Notifications 

[0093] In the present embodiment access to Events 
(Notifications) is controlled in the same way as access 
to objects, using rules in the access control rule base. 
X.741 does not include event notifications as one of the 
types of operation types to which the access control 
mechanism of X.741 is applicable. An example of the 
event notification access control problem is as follows, 
a telephone network provider does not want customer 
A to receive notifications about new network resources 
installed for customer B, but customer A registers itself 
to receive all event notifications. 
[0094] The present embodiment solves the event no- 
tification access control problem by (A) adding event no- 
tifications to the set of operation types that are governed 
by rules in the access rules database, and (B) adding a 
filtering mechanism to the system's event router that fil- 
ters event notification messages based on the rules in 
the access rules database. 

[0095] Thus, when a target object is defined in the ac- 
cess control object tree 170, one of the operations that 
can be specified in the target object's operations list is 
"event notifications". In a preferred embodiment, the 
event notification operation specified in a target object 
can either specify all event notifications for a set of spec- 
ified management objects, or it can specify certain spe- 
cific types of event notifications by using the filter field 
of the target object to specify the types of event notifi- 
cations to be included in the target object. For instance, 
a target object might apply to SNMP or CMIP generated 
events, but not to other types of events such as object 
creation and deletion events. 

[0096] Further, a particular target object can be used 
to define access rights to a set of management objects 
for several operations including event notifications. For 
instance, a target object that is to be used with a deny 
rule for denying access to any and all information re- 



garding a particular set of management objects will typ- 
ically include event notifications in its list of operations. 
Alternately, when appropriate, separate target objects 
can be used to define event notification access rights. 
s [0097] Referring to Fig. 8, the MIS 150 maintains an 
event registry 184. More accurately, the event registry 
184 is a software module that maintains a table 260 of 
user event requests. The MIS directs all access re- 
quests whose specified operation type is "event notifi- 
io cation" tothe event registry 184, regardless of which ob- 
jects are specified by the request. The table 260 stores 
information denoting, for specified event notifications 
that can be generated by either the management ob- 
jects or the access control objects, which users or other 
'5 entities have registered a requested to receive copies 
of those event notifications. The event registry table 260 
only stores information about events that users and oth- 
er entities tiave requested. The event notification regis- 
tration requests (which are access requests with an op- 
20 eration type equal to "event notification") can be speci- 
fied either in terms of specified objects, specified class- 
es of objects, or specified subtrees of objects. Thus, for 
instance, a user could request receipt of all event noti- 
fications for router objects (i.e., which is a class of ob- 
25 jects), and could further specify a filter, such as only 
routers located in the state of California or routers man- 
ufactured by a particular company. Users and entities 
can also revoke prior requests. 
[0098] In the preferred embodiment, the event regis- 
30 try 1 84 only checks registration requests to ensure that 
the requests are semantically correct and that the spec- 
ified objects for which events are requested actually ex- 
ist. Thus, in the preferred embodiment the event registry 
184 does not check to see if the user or entity making a 
35 registration request has the security clearance to actu- 
ally receive the requested notifications. That job is given 
to the event router 186, which checks event notification 
access rights at the time each event notification is being 
processed. As a result, any changes in a user's access 
40 rights to event notifications are taken into account by the 
event router and do not affect the information stored in 
the event registry 184. 

[0099] Entities other than users that can register to 
receive event notifications include: the MIS 150 and 
45 auxiliary servers 152, the log server (which will be dis- 
cussed below), and even objects (e.g., database ob- 
jects, which are discussed below) that are part of the 
access control engine. 

[0100] All event notifications, including event notifica- 
50 tions generated by management objects (indicated by 
"other event sources" in Fig. 8) and event notifications 
generated by access control objects (indicated by the 
special auxiliary server 154 in Fig. 8), are delivered to 
the event router 186 in the MIS 150. The event router 
55 1 86 also has access to the access control tree 1 70 and 
the table of user event requests 260 in the event registry 
184. For each event notification received by the event 
router 186, the event router first determines which users 
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and entities have requested a copy of that event notifi- 
cation, and then determines which of those users and 
entities have the right to receive those event notifica- 
tions. The determination of access rights to event noti- 
fications is performed using the access control decision 
function, as shown in Fig. 5. Thus, the event router 
looks, in sequence, at the global deny rule, the targeted 
deny rules, the global grant rule and the targeted grant 
rules until a matching rule is identified. A default rule is 
applied if not matching rule is found. A matching rule 
must (A) apply to the "event notification" operation, (B) 
apply to the object that generated the event notification, 
and (C) apply to a group of which the requester is a 
member. 

[0101] For each requester of an event notification that 
has access rights to that event notification, the event 
router generates a corresponding event notification 
message, each of which is addressed to a single author- 
ized user or entity. Thus a single event notification may 
result in zero event notification messages, or many, de- 
pending on the number of requesters with correspond- 
ing access rights. 

[0102] One specific application of the event registry 
184 and event router 186 used in the preferred embod- 
iments is as follows. There is a special auxiliary server 
154 that handles all access requests to and modifica- 
tions of the access control tree 170. In other words, ac- 
cess requests (other than event notification access re- 
quests) whose target set is located in the access control 
tree 170 are routed by the MIS 150 to the special auxil- 
iary server 154. Furthermore, all changes to the access 
control tree 170 result in the generation of event notifi- 
cations that are sent to the event router 186. In particu- 
lar, the creation of new access control objects, the de- 
letion of access control objects, and the modification of 
the attributes of any access control object, all result in 
the generation of event notifications. 
[0103] The MIS 150 and auxiliary servers 152 are all 
automatically registered in the event registry 184 to re- 
ceive all event notifications related to changes in the ac- 
cess control tree 1 70. The Ml S 1 50 and auxiliary servers 
are also included in a set of "super users" with access 
rights to all event notifications. Furthermore, among the 
library procedures shared by the MIS 150 and auxiliary 
servers 152 is an event receiving and processing pro- 
cedure 262. When the MIS 150 and auxiliary servers 
152 receive any event notifications indicating a change 
in the access control tree 1 70, the event processing pro- 
cedure 262, which is invoked by each server, makes the 
same change to the server's local copy of the access 
control tree 170. As a result, the local copies of the ac- 
cess control tree 170 in each of the servers 150, 152 
are updated virtually simultaneously. 

Direct Database Access to Management Information 

[0104] X.741 does not call for, or even suggest, SQL 
access to the management object database. In fact, di- 



rect access via a DBMS mechanism might be seen as 
contrary to the goals of X.741 since it is a potential 
source of security leaks. However, corporate customers 
of large communication networks are demanding direct 
5 "read only" access to management information for pur- 
poses of report generation. 

[0105] The direct access mechanism of the present 
embodiment provides limited, read only access to man- 
agement information using standard DBMS report gen- 

10 erators to define and generate reports about the status 
or past performance of network objects. This is conven- 
ient for users, and avoids the complexities of network: 
management information retrieval using SNMP (or any 
other network management protocol) when the only task 

15 to be performed is the generation of status reports and 
other network system analysis reports. 
[0106] The direct access mechanism of the present 
embodiment only allows users access to information 
that would be granted if requested via the normal man- 

20 agement interface to the network. 

[0107] Referring to Fig. 9, the primary components of 
the direct information access mechanism are: a conven- 
tional database management system (DBMS) 280 for 
storing event logs 282, each of which stores event no- 

25 tifications to which various users have requested direct 
SQL type access; and a log server 290 whose primary 
function is to convert event notifications into. SQL insert 
statements for storing event notifications in the event 
logs. 

30 [0108] The DBMS 280, being conventional, stores ta- 
bles of information. While Fig. 9 shows event logs 282, 
each event log is actual one or more database tables, 
where each database table stores a different type of 
event notification. The DBMS 280 also has an access 

35 privileges module 284 which configures (i.e., establish- 
es) access rights to each of the tables in the DBMS. For 
instance, the access privileges module 284 may have 
an access privileges table that stores access rights in- 
formation indicating which users have access to the ta- 

40 bles that make up the event logs 282. However, the ac- 
cess privileges module 284 may be implemented in oth- 
er ways, such as by storing access privileged informa- 
tion with each database table. The present application 
does not depend on the particular mechanism used by 

45 the access privileges module 284 to establish database 
table access rights. 

[0109] In the preferred embodiment, only the log serv- 
er 290 (besides the system administrator) has write ac- 
cess to the event log tables, while specified users have 

50 read access to specific tables. A standard SQL engine 
286 processes insert statements from the log server 290 
as well as read requests from user processes or work- 
stations 300 that are submitted via a user communica- 
tions interface 288. 

55 [0110] The log server 290 is registered with the event 
registry to receive all event notifications generated by 
the system, and has corresponding access rights. The 
log server 290 is preferably a software entity or process 
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that runs on the same computer or computer node as 
the MIS 150. A set of filters 291, 294 in the log server 
290 determine which event notifications are stored, as 
well as where. A first filter 291 in the log server is called 
the security audit trail filter. This filter 291 passes "ac- 
cess grant" and "access denial" event notifications gen- 
erated by the MIS 150 and auxiliary servers 152 (see 
Fig. 8). The security audit trail filter 291 can selectively 
store either the entire event notification, or a specified 
portion of it, in the security audit trail file 182. More spe- 
cifically, when the security audit trail is configured to 
work in a detailed mode, the security audit trail 182 
stores every access request and the corresponding out- 
come in its entirety. When the security audit trail is con- 
figured to work in an abbreviated mode, the security au- 
dit trail 182 stores a shortened representation of every 
access request and the corresponding outcome. 
[0111] Another log server filter 292, called the security 
alarm filter, is used to generate a Security Alarm log 293 
that is separate from the security audit trail 182, where 
security alarms are generated and stored in the log only 
when there is a denial of object access. In the preferred 
embodiment the stored security alarms identifies the us- 
er that initiated each denied access request. 
[0112] The other type of log server filter shown in Fig. 
9 are the event log filters 294. Each event log filter is set 
up to pass only a specified set of event notifications. For 
instanceaparticularcustomer might request that certain 
groups of its employees have direct access to all SNMP/ 
CMIP event notifications for management objects as- 
signed to that customer. The log create/delete proce- 
dure 296 is used to define a corresponding event log by: 

(A) defining and initializing a corresponding set of 
DBMS tables 282 (i.e., an event log) for storing the 
requested event notifications (one distinct DBMS 
table per distinct event notification type); 

(B) defining and creating a database object 298, 
and registering the database object 298 with the 
event registry to receive event notifications affect- 
ing the rights of users to receive those event notifi- 
cations; the database object 298 includes a first at- 
tribute that contains a list of the DBMS tables in 
which the event log is stored, and a second attribute 
that contains a list of the groups with access rights 
to the event notifications; 

(C) as group names are first added to the database 
object 298, the database object 298 sends an initial 
set of database table access grant commands to 
the DBMS to define the initial set of users with ac- 
cess rights to the tables making up the event log 
282; and 

(D) defining and creating an event log filter 282 for 
passing only the requested event notifications and 
for converting them into SQL insert statements for 
inserting each passed event notification into a cor- 
responding one of the DBMS tables. 



[0113] For each event log 282 there are one or more 
corresponding target objects in the access control ob- 
ject tree 170 that define (1) the target set of manage- 
ment objects for which event notifications are to be 

5 stored in the event log, and (2) the types of event noti- 
fications to be included in the event log. For any partic- 
ular event log, the set of groups of authorized users must 
be the same for all event notifications in that event log. 
Any changes in the groups of users to be granted access 

10 to the event log are communicated to the corresponding 
database object 1 98 by registering the database object 
with the event registry to receive event notifications 
about attribute changes to the target object(s) corre- 
sponding to the event log. The database object 298 is 

is also registered to receive event notifications of attribute 
changes to the group objects for the groups that have 
access rights to the event log. 

[0114] Whenever the database object 298 for a par- 
ticular event log 282 is notified of a change (i.e., addi- 

20 tions and/or deletions) in the membership of one of the 
groups with access rights to the event log 291, or a 
change in the set of groups to be given access to the 
event notifications in the event log, the database object 
298 sends corresponding access grant and access re- 

25 voke commands to the DBMS 280. The access privileg- 
es module 284 then reconfigures the database table ac- 
cess rights accordingly. 

[0115] As event notifications corresponding to an 
event log are generated, they are forwarded by the 
30 event router 186 to the log server 290. The log server 
290 forwards them to the event log's filter 294, where 
they are converted into SQL insert statements and sent 
to the DBMS 280 for storage. If some of the same event 
notifications are included in two (or more) different event 
35 logs 282, the same event notification will be stored two 
(or more) times in different tables of the DBMS. 
[0116] The SQL engine 286 enforces previously de- 
fined access restrictions to the event logs. In particular, 
every user query for information from the tables in the 
40 DBMS is checked by the SQL engine 286 against the 
access rights established by the access privileges mod- 
ule 284, and only queries in full compliance with those 
access rights are processed. User queries requesting 
information from tables to which the user does not have 
45 access rights are rejected by the SQL engine 286. 
[011 7] Because user requests for information from the 
DBMS 280 must be submitted in the form of SQL que- 
ries, all the report generator tools available for the 
DBMS can be applied to creating SQL queries for man- 
so agement information. Thus, the DBMS access mecha- 
nism shown in Fig. 9 provides the convenience of using 
fast and well known DBMS access tools while still pro- 
viding the same access restrictions as those provided 
by the management information server. Furthermore, 
55 the access restrictions imposed by the DBMS 280 are 
automatically updated whenever the access rights to the 
corresponding event notifications are modified in the 
main access control engine that controls access to in- 
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formation in the management object tree. 



1. An access control system for controlling access to 
management objects in a distributed network, com- 
prising: 

an access control database, including access 10 
control objects, the access control objects in- 
cluding: 

group objects, each defining a group and 

a set of users who are members of the 15 

group; and 

rule objects, a subset of the rule objects 
each specifying: a set of the group objects, 
a set of the management objects, and ac- 
cess rights by the users who are members 20 
of the groups defined by the specified set 
of the group objects to the specified set of 
management objects; and 

a plurality of access control servers, each ac- 25 
cess control server controlling access to a dis- 
tinct subset of the management objects in ac- 
cordance with the access rights specified in the 
access control database; wherein at least one 
of the access control servers receives access 30 
requests from the users and distributes the re- 
ceived access requests among the access con- 
trol servers for processing; a subset of the ac- 
cess requests specifying operations to be per- 
formed on specified sets of the management 35 
objects; wherein each access request in the 
subset is sent for processing to one or more of 
the access control servers in accordance with 
the management objects to which access is be- 
ing requested by the access request; 40 
the access control servers responding to the 
access requests from the users by granting, de- 
nying and partially granting and denying the ac- 
cess requested in each access request in ac- 
cordance with the access rights specified in the *s 
access control database. 

2. The access control system of claim 1 , wherein 

one of the access control servers is a manage- so 
ment information server that receives the ac- 
cess requests submitted by users to the access 
control system; 

the management information server includes 
means for partitioning an access request into ss 
two or more access sub-requests when the ac- 
cess to the set of management objects speci- 
fied by the access request is controlled by two 



or more of the access control servers and send- 
ing the access sub-requests to those two or 
more access control servers for processing; 
and 

the management information server includes 
means for combining responses to the two or 
more access sub-requests generated by the 
two or more of the access control servers after 
processing the access sub-requests and re- 
turning a combined response to the user who 
submitted the access request that was parti- 
tioned. 

3. The access control system of claim 1, wherein 

a second subset of the rule objects in the ac- 
cess control database specify: a set of the 
group objects, a set of the access control ob- 
jects, and access rights by the users who are 
members of the groups defined by the specified 
set of the group objects to the specified set of 
access control objects; and 
the access control system includes an access 
control database server that stores the access 
control database in persistent storage, receives 
access requests to the access control objects, 
grants and denies the access requests to the 
access control object in accordance with the 
access rights specified in the access control da- 



4. The access control system of claim 1 , wherein 

a second subset of the rule objects in the ac- 
cess control database each specify: a set of the 
group objects, a set of the management ob- 
jects, and access rights by the users who are 
members of the groups defined by the specified 
set of the group objects to event notifications 
generated by the specified set of management 
objects; and 

the access control system includes an event 
router that receives event notifications gener- 
ated by the management objects and sends 
corresponding event notification messages on- 
ly to users in groups who have access rights to 
those event notifications in accordance with the 
access rights specified in the access control da- 



5. The access control system of claim 4, wherein 

the access control system includes an event 
registry for registering event notification re- 
quests by users, each event notification re- 
quest specifying event notifications from spec- 
ified sets of the management objects that are 
being requested; 
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the event router including means for sending, 
in response to each received event notification, 
corresponding event notification messages to 
users who have registered a corresponding 
event notification request with the event regis- s 
try and also have access rights to the received 
event notification in accordance with the ac- 
cess rights specified in the access control da- 
tabase. 

A method of controlling access to management ob- 
jects in a distributed network, comprising the steps 
of: 

storing a set of access control objects, the ac- 15 
cess control objects including: 

group objects, each defining a group and 
a set of users who are members of the 
group; and 20 
rule objects, a subset of the rule objects 
each specifying: a set of the group objects, 
a set of the management objects, and ac- 
cess rights by the users who are members 
of the groups defined by the specified set ^ 
of the group objects to the specified set of 
management objects; and 

receiving access requests from the users and 
distributing the received access requests 30 
among a plurality of access control servers for 
processing; a subset of the access requests 
specifying operations to be performed on spec- 
ified sets of the management objects; each ac- 
. cess control server controlling access to a dis- 35 
tinct subset of the management objects in ac- 
cordance with the access rights specified in the 
access control database; wherein at least one 
of the access control servers; wherein each ac- 
cess request in the subset is sent for process- fo 
ing to one or more of the access control servers 
in accordance with the management objects to 
which access is being requested by the access 
request; 

at the access control servers, responding to the 45 
access requests from the users by granting, de- 
nying and partially granting and denying the ac- 
cess requested in each access request in ac- 
cordance with the access rights specified in the 
access control database. 50 

The access control method of claim 6, wherein 

receiving at one of the access control servers 
all the access requests submitted by users; 55 
at the one access control server, partitioning an 
access request into two or more access sub- 
requests when the access to the set of man- 



agement objects specified by the access re- 
quest is controlled by two or more of the access 
control servers and sending the access sub-re- 
quests to those two or more access control 
servers for processing; and 
at the one access control server, combining re- 
sponses to the two or more access sub-re- 
quests generated by the two or more of the ac- 
cess control servers after processing the ac- 
cess sub-requests and returning a combined 
response to the user who submitted the access 
request that was partitioned. 

8. The access control method of claim 6, wherein 

a second subset of the rule objects in the ac- 
cess control database specify: a set of the 
group objects, a set ol the access control ob- 
jects, and access rights by the users who are 
members of the groups defined by the specified 
set of the group objects to the specified set of 
access control objects; and 
at an access control database server, storing 
the access control database in persistent stor- 
age, receiving access requests to the access 
control objects, granting and denying the ac- 
cess requests to the access control object in 
accordance with the access rights specified in 
the access control database. 

9. The access control method of claim 6, wherein 

a second subset of the rule objects in the ac- 
cess control database each specify: a set of the 
group objects, a set of the management ob- 
jects, and access rights by the users who are 
members of the groups defined by the specified 
set of the group objects to event notifications 
generated by the specified set of management 
objects; and 

at an event router, receiving event notifications 
generated by the management objects and 
sending corresponding event notification mes- 
sages only to users in groups who have access 
rights to those event notifications in accord- 
ance with the access rights specified in the ac- 
cess control database. 

10. The access control method of claim 9, wherein 

at an event registry, registering event notifica- 
tion requests by users, each event notification 
request specifying event notifications from 
specified sets of the management objects that 
are being requested; 

at the event router, sending, in response to 
each received event notification, correspond- 
ing event notification messages to users who 
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have registered a corresponding event notifica- 
tion request with the event registry and also 
have access rights to the received event notifi- 
cation in accordance with the access rights 
specified in the access control database. 
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